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Chapter 5 



Demand Management 



Demand management encompasses the areas of forecasting, customer order en- 
try, distribution, and interplant movement of material and as such is an integral 
part of the high level planning and scheduling process. In a manufacturing com- 
pany, forecasts and the backlog of customer orders are the starting point for com- 
pany business plans, the sales and operations planning process, and the master 
production schedule. The customer orders also may identify future requirements 
for the final assembly schedule. In a distribution business, demands from physical 
distribution play a major role in the development of valid production plans and 
master production schedules. 

Demands are one of the inputs to the sales and operations planning and master 
production scheduling processes. The demands for a product family or item are 
not the sales and operations plan or the master production schedule itself. Instead, 
they are combined in a process of human judgment and evaluation to produce a 
valid sales and operations plan and individual master production schedules. 

The purpose of demand management is to develop the most reasonable projec- 
tion of future requirements, and then update this projection when change is war- 
ranted. By properly managing the different demand streams, trivial changes to 
the sales and operations plan and master schedule can be avoided — and meaning- 
ful differences in the marketplace can be recognized at the earliest possible mo- 
ment so that effective action can be taken. 

The demand management capabilities in the system must recognize that fore- 
casting, customer order promising, etc. are a people process, and that the essence 
of effective demand management is good communication, quick feedback, and 
properly defined accountabilities. The computer logic that is part of an effective 
demand management system should support these important activities. 

FORECASTING SYSTEM 

For most companies, a significant portion of the demand management and high- 
level planning activities starts with the forecast. Forecasts are a primary input to 
the business plan, the sales and operations plan, and the master production sched- 
ule. The management of a company and the master scheduler must evaluate the 
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forecast along with the other factors that make up the business plan, sales plan, 
and the master production schedule. 

Forecasting, like many business functions, is a management process with spe- 
cific accountabilities: it also happens that for many companies the computer can 
provide significant assistance in developing and updating the forecast. In the end, 
though, people evaluate and approve forecasts and develop sales plans to make 
the forecast happen. Ultimately, people have to be held accountable for hitting 
the forecast. 

A comprehensive forecasting system should have four basic functions: 

1 . Several simple forecasting techniques and a method for evaluating these dif- 
ferent techniques . 

2. A way to take seasonal factors into account. 

3. A way to break down and allocate forecasts of families of items by warehouse, 
configuration, package size, etc. 

4. A way to review and approve the forecast before updating the system. 

The functions that should be part of a comprehensive forecasting system devel- 
oped over a number of years of experience working with forecasting systems. For 
a long time, there were two major misconceptions about forecasting. One mis- 
conception was that it was possible to develop a "right number"; that by devel- 
oping more and more sophisticated and complicated forecasting algorithms it would 
be possible to compute the right number. The other misconception was that it was 
possible to develop a single technique that would work to forecast all items. 

For many years, most research on forecasting focused on sophisticated mathe- 
matical approaches like multiple regression analysis, least squares, correlation 
analysis, adaptive smoothing, Box Jenkins, etc. This was an attempt to develop 
a single sophisticated forecasting technique that would generate the right forecast, 
mid which would work for all items. 

Unfortunately, with each increase in sophistication came a corresponding de- 
crease in the ability of humans to evaluate and use the forecasts, with little im- 
provement in forecast accuracy. 

Most of the effort expended in developing forecasting techniques has been in 
Ine area of mathematical optimization. Yet experience shows that if people don't 
MM Icrstand why a system produces certain numbers or recommendations, typi- 
tvJ , h CCaUSe ° f the com Plexity of the mathematics used to develop those num- 
wlvin .■ they W ' U n0t be able t0 USe the s y stem effectively. In most cases, the 
, C V n forecastin g techniques have actually made it more difficult to under- 
hand us e the forecasts that can be generated, 
hwunhri ^ tr ° nd ' S Waning awa y from mathematical optimization and moving 
•M will .. ! tlng aIternatives - Ins tead of trying to find the single right formula 
hiii,i|J,I U d - ff? rate thC ° nC " ght forecast > companies are using the computer to 
Dillon ' f ent forecasti ng strategies and evaluate their effectiveness. People 
lew the different strategies and the recommendations of the forecast- 
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ing system, choosing the technique that makes the most sense in developing a 
forecast of future sales. 

This approach to forecasting is called focus forecasting (Focus Forecasting: 
Computer Techniques for Inventory Control, Bernard T. Smith, Oliver Wight 
Limited Publications, Essex Junction, Vermont, 1978). Focus forecasting is a 
system that can simulate and evaluate a number of different strategies, selecting 
the forecasting technique that would have proven most effective in forecasting 
the recent past. The forecasting techniques that are part of a focus forecasting 
system are typically simple techniques like a moving average or simple strategies 
like "whatever we sold the last three months is probably what we'll sell the next 
three months," but they could be sophisticated mathematical approaches. In ad- 
dition, some companies may also find it important to include models of product 
life cycles for assistance in forecasting. All these techniques are accommodated 
by the focus forecasting approach. 

Most people using focus forecasting systems end up choosing simple forecast- 
ing strategies because they are easy to understand and use. In addition, the bene- 
fits from focus forecasting come from using a computer to simulate alternatives, 
rather than from using it for a single sophisticated technique to develop the "right 
answer." 

Effective forecasting software accommodates both the intrinsic and the extrin- 
sic factors that may make up a forecast. Intrinsic forecasts are based on the past. 
The most common ways to make these predictions use an average, a moving 
average, or a weighted moving average. The extrinsic forecasts are based on 
outside information like marketing information, etc. 

The strategies that are part of a forecasting system must provide a way to take 
seasonal factors into account. This would allow the system to handle regular 
patterns that repeat at certain times each year. For example, demand for both 
cigars and cosmetics is highly seasonal. This seasonality can be analyzed and 
some numbers developed for each time period. These numbers, often called base 
indices, can then be used to spread the total forecast over the year, quarter, or 
month in whatever pattern makes sense. 

The forecasting system must also provide a way to break down and allocate 
forecasts for families of items by warehouse, configuration, package size, etc. In 
a Distribution Resource Planning system, for example, it is necessary to develop 
sales forecasts by item and distribution center. Many companies choose to de- 
velop a nationwide forecast, and break it down into individual item and distribu- 
tion center forecasts. This breakdown would typically use historical percentages. 
This same approach can be used to take an overall product family forecast and 
break it down to specific forecasts by product configuration or package size. 

Similarly, the system must provide a method for reconciling the aggregate fore- 
cast for a product family with the sum of the individual forecasts by item. Rec- 
onciliation of the forecasts might mean adjusting the aggregate forecast in some 
situations. In other situations, the individual forecasts might be recomputed using 
a proration of the aggregate forecast. 

Finally, and perhaps most importantly, a forecasting system must have a way 
to review the forecast after it has been generated and before the system is updated. 
The experience of operating effective forecasting systems shows that the key is 
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to combine simple forecasting techniques with good human judgment. A human 
being will be responsible for the forecast, and a human being needs to review it 
before it is updated. A person must have the opportunity to change the forecast 
before it goes into the system so that he or she can be held accountable for the 
forecast being used. 



ORDER ENTRY SYSTEM 

An order entry system is used to add, delete, and change customer orders. If 
the item ordered by the customer is planned by MRP, the customer order will be 
presented to the MRP netting and exception checking logic as a demand. If the 
item is controlled through the master scheduling system, these customer demands 
will be presented to the master production scheduling netting and exception logic. 

The order entry system must be able to create multiple line items on a single 
customer order. The multiple line items may be for different items on the same 
date, for different items on different dates, or for the same item on different 
shipment dates. Each line item represents a demand to MRP or the master sched- 
uling system. One or more shipments may be included on a single customer order. 

Five pieces of information are required for each customer order line item. These 
are the item number, required (promised) date, quantity, customer order number, 
and customer request date. The item number is used to present the customer order 
information to MRP and master scheduling. The required date and quantity are 
used in the netting and exception logic. The customer order number is needed for 
pegging. The customer request date is the date the customer originally specified 
for the line item, and may be different from the required date or promised date 
that is being used in the MRP or master scheduling system. For example, the 
customer may have asked for the item in week three, but, because of supply 
problems, it will not be available until week six. In this case, the date the cus- 
tomer is promised is week six, but the request date for the item is week three. 
The customer request date is needed for an available-to-promise check when the 
order is entered, and can be helpful for performance measurement, forecasting, 
and forecast consumption. 

Besides having the capability to create customer orders and customer order line 
items, the order entry system must be able to change and delete existing orders. 
Once a customer order has been created, the information must be available for 
change. It must be possible to change the required date and the quantity for each 
line item. When a customer order is deleted, the system should close the order 
Mid remove each of the line items regardless of the order status. When a customer 
•'ttlei' line item is deleted, the system should remove the line item, and if all line 
items are completed or closed, mark the order complete. 

Paperwork to assist the stockroom or finished goods inventory people may be 
liulpiul and can be produced when the customer order is ready for shipment. This 
u"i"''t! tCr generated P a P erwork typically includes picking lists and shipping doc- 
^ ' "gic for producing hardcopy customer confirmations may be helpful. Confir- 
it!'li'l" 1S a,1C typically printed immediately following the creation of all the line 
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The order entry process should include an available-to-promise check for each 
line item on the customer order. As explained in Chapter 4, Master Production 
Scheduling, by promising customer orders using the available-to-promise calcu- 
lation new customer orders can be slotted for shipment based on the existing 
master production schedule. 

There are a number of different ways to do an available-to-promise check: 

1. In cases where the customer promise is made before the order is entered, the 
available to promise has to be checked prior to the actual entry. 

A. Done using the master production schedule report or display. 

B. Done using special on-line promising displays to automate the checking 
and promising process. 

2. The available to promise checked as the order is entered, with items not avail- 
able on the requested date highlighted and shown with both the requested date 
and the available date for review by a person. 

3. Available-to-promise check run after the order is entered with orders not avail- 
able on the requested date listed on a report or in an on-line display for reprom- 
ising. 

An automated check of the available to promise normally works by comparing 
the cumulative available to promise on the request date with the quantity required 
on the customer order. The available to promise for the first period is the on-hand 
balance plus master schedule orders due in the past or current period less all 
customer orders due before the end of the first period. For later periods, the 
available to promise is the prior period available to promise plus any master schedule 
orders less any customer orders for the period. The customer order quantity is 
compared to the available-to-promise quantity for the period of the request date. 
If the available to promise is greater than or equal to the requirement, then the 
line item can be promised. 

If the available to promise is less than that required, then a person has to make 
a decision about the importance of changing the master production schedule for 
this single customer order. A good master production schedule policy recognizes 
that there is an expense in direct and setup labor, inventory, overhead, and con- 
fusion for each change to the master production schedule. Yet changes can and 
should be made to the schedule. The policy should be to provide an evaluation of 
the effects and cost of each change prior to the change being made. 

The order entry system requires some additional capabilities to handle customer 
orders for products made-to-order from a number of options. This type of product 
is like the automobile described in the master production scheduling chapter (Chapter 
4). For automobiles, modules exist for V-8 and V-6 engines, AM-FM radios, 
accessory trim packages, etc. These modules may be actual subassemblies that 
are stocked and then put into the automobile (for example, the V-6 and V-8 
engine options), or they may be logical groupings of parts that cannot physically 
be assembled (like accessory trim packages). The parts associated with this type 



Demand Management / 63 



of module are put together with the parts of other modules to create a number of 
different subassemblies, like the front and rear door subassemblies. 

In this type of product, the customer order is not for a specific finished item 
number from a product catalog. Instead, the customer order is for a type of prod- 
uct and a series of options. For example, the customer order might be for a silver 
Buick Skylark automobile with V-6 engine, AM/FM cassette stereo, special trim, 
etc. The customer order is the only unique product identifier, and it is entered at 
two levels: for the type of product (Buick Skylark) and modules and options 
(Buick Skylark common parts module, V-6 engine option, AM/FM cassette op- 
tion, etc.). 

For products made from options, the order entry mechanism should include 
two additional capabilities: 



1. Assistance in selecting the proper modules and options for the product. 

2. A check of the available to promise for both the type of product and each 
option. 

The order entry mechanism should provide a menu of available choices for 
each type of product. For example, the order entry system should prompt for the 
entry of the type of product; show that an engine option is required, displaying 
the available choices of engines; show that the transmission option is required, 
displaying the available choices for transmissions, etc. And, since not all options 
necessarily work with all other options (for example, in the case of the Buick 
Skylark, the 5-speed manual transmission option may only be available with the 
4-cylinder engine), the system should eliminate the choices that are not valid 
based on earlier choices. This way, once the order entry person picked a Skylark 
with 6-cylinder engine, the system would not show the 5-speed transmission as 
an available option. 

For a product made from options, the customer request date is a single date, 
but product availability is based on the dates of the individual options and mod- 
ules. Consequently, the order entry mechanism should check the available to 
promise for the type of product and the available to promise for each product 
option. If all of the modules and options are not available by the requested date, 
then the order should be flagged for human review and approval. 



METHOD FOR ANALYZING CUSTOMER ORDERS 

Not all customer orders are necessarily part of the forecast. Sometimes major 
orders are received from new customers, and sometimes high-impact orders are 
Kttlhcoming from new, unanticipated market segments. At other times, changes 
•» »ic marketplace may be signaled by significant increases (or decreases) in cus- 
tomer order demands. 

( Unless mechanisms exist to identify abnormal demands (and give them some 
>P*J ot special handling) and to pick up trends in the marketplace, a company 
wivt J »? Pardize its abmt Y to service existing customers that are part of the fore- 

'■• • Abnormal demands are not part of the forecast, they are in addition to the 
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forecast quantities. Major volume increases indicate that the forecast is being 
oversold and that the forecast needs to be revised. If the system assumes that 
these abnormal demands or volume increases replace the forecast, then the total 
demand for the item will be significantly understated in the system. Not enough 
of the required items will be built to satisfy the real demands. Eventually, the 
excitement of the major new accounts may be dampened by the problems that 
come from being without a product genuinely needed to support the needs of 
long-term, loyal customers. 

Consequently, some method is needed to assist in analyzing incoming customer 
orders. This has two parts: 

1 . Computer logic to compare existing customer orders to the forecast for the 
purpose of identifying demands that may be abnormal, or major shifts in the 
marketplace. 

2. A way to code demands that have been identified as abnormal. 

The volume of orders promised in many companies makes identifying abnor- 
mal demands manually a challenging, if not impossible, job. For this reason, 
simple computer logic to compare customer orders, individually and in groups, 
to forecasts is helpful. This logic can assist in identifing abnormal demands. 

Generally, companies set up some simple rules, such as: 

1 . Individual customer orders that exceed X% of the forecast quantity for the 
period are potentially abnormal. 

2. Total customer orders exceeding Y% of the forecast for a specified period may 
be abnormal or indicative of an upward business trend that should be reviewed. 

3. Customer orders less than Z% of the forecast for a specified period may be 
indicative of a downward business trend that should be reviewed. 

4. Total customer orders through a period (all the orders between the current date 
and the specified future period) exceeding some specified percentage of the 
total forecast may be abnormal or indicative of an upward business trend that 
should be reviewed. 

5. Total customer orders through a period (all the orders between the current date 
and the specified future period) less than some specified percentage of the total 
forecast may be indicative of a downward business trend that should be re- 
viewed. 

6. An unsold forecast quantity that has fallen past due and that exceeds some 
percentage of the month's forecast may be indicative of a downward trend that 
requires review. 

Customer orders in excess of the limits can be coded as abnormal demands auto- 
matically, or listed on an exception report for review by someone who can eval- 
uate the situation. A person would be responsible for reviewing the situation and 
deciding if additional actions should be taken. This way, early communication 
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with the customer may avert bad commitments and future service problems. In 
situations where the customer orders are less than the limits, the items should be 
listed on an exception report for human review. 

Abnormal demands should be excluded from the forecast consumption logic 
that is part of the system (and described below). Abnormal demands should be 
added to the remaining forecast, other customer orders, etc. to compute total 
demand against the master schedule. Demands coded as abnormal may need to 
be excluded from the forecasting process because they represent events not likely 
to happen again in the future. 



FORECAST CONSUMPTION LOGIC 

The system should also include a method to reduce the forecast by customer 
orders that are part of the forecast. The objective of this forecast consumption 
logic is to most accurately represent the needs of the marketplace based on current 
projections and actual orders. By consuming the forecast properly it is possible 
to compute total customer demand for each period, taking into account timing 
differences between the actual customer orders and the forecast. These timing 
differences can occur when customer demands match the forecast quantities, but 
are for different dates than those anticipated. 

Forecast consumption logic can be done in either of two places: 

1 . As customer orders are entered. 

2. In a separate calculation that is run periodically. 

Either of these two methods is workable. In the first case, the unconsumed fore- 
cast is updated as each customer order is entered. The system finds the proper 
unconsumed forecast quantities and reduces them by the customer order quantity. 
In the second case, the forecast consumption logic is part of a separate calculation 
and not part of the order entry process. In other words, the forecast is left un- 
changed as customer orders are received. In a separate computation, either as part 
of the master production schedule report or a separate batch run, the customer 
orders are combined with the original forecast to compute the unconsumed fore- 
cast. 

^ In each of these methods, both the original forecast and the unconsumed fore- 
cast are stored in the system. The original forecast is needed so that customer 
orders can be reanalyzed periodically to identify potentially abnormal demands 
WW trends. By storing the unconsumed forecast, the master scheduling and ma- 

•nal requirements planning logic is simplified. The unconsumed forecast can be 
« «cd to the other demands to compute total demand for the item. No forecasts 

'"sumption calculations are required in the MRP or master production schedul- 
I if 0 t0 C ° mbine the ori g inal forecast and the customer orders. 
I* red f °I eCaSt consum P tio n logic that is part of the system, the forecast should 

Wmsdto l f Peri ° d ' n WhiCh the customer order is re q uested - If demand 
lot,.,. J fore cast in the period, the system can reach ahead or back to reduce 
"»w.asts in other time periods. 
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It is also necessary to provide logic to handle forecasts and customer orders 
that fall past due. It is incorrect to drop off the unconsumed forecast at the end of 
each week. In most situations, this has the effect of changing the forecast — even 
though no change was intended or indicated. For example, take the situation 
where the original forecast for a month was forty, split into four weekly quantities 
of ten. At the end of week one, only seven have been sold. Should the system 
drop the unsold three from the forecast? If so, the forecast has now been revised 
from forty to thirty-seven? Or should the remaining three units accumulate as an 
unsold forecast, in effect leaving the original forecast of forty for the month with- 
out change? 

The simplest way to handle this problem is to specify the number of weeks that 
should be accumulated in the past due time period before being dropped. For 
example, four weeks could be specified. Unconsumed forecasts would accumu- 
late in the past for a month, and then be dropped automatically. In most situa- 
tions, an exception report should list the forecasts that were dropped automatically; 
this way, a person can review the situation and add back a forecast quantity if it 
was dropped in error. 

When the forecast consumption logic is part of a separate batch process in the 
system, some additional logic is needed in the mechanism that drops unconsumed 
forecasts. This additional logic recodes any past due customer orders in the sys- 
tem as abnormal demands when the unconsumed forecasts are dropped. This pre- 
vents the system from incorrectly consuming the forecast in future time periods 
with these customer orders. 

An effective system includes a calculation of total demand that summarizes the 
unconsumed forecast, normal and abnormal customer orders, dependent de- 
mands, distribution requirements, and interplant orders by date. This total de- 
mand is used in developing and managing the sales and operations plan and the 
master production schedule. 

INDEPENDENT DEMAND 

The system must also provide a way to enter independent demands into the 
MRP system. These independent demands are not apart of the master production 
schedule but are included in MRP. 

This method for entering independent demands into the system is used for spare 
parts as well as items where the need for human control through the master pro- 
duction schedule is not needed. These items have no significant effect on capacity 
or materials, and no human evaluation is needed to evaluate the need or ability to 
change the schedule. 

Independent demands are entered into MRP as gross requirements. The gross 
requirements are added to any exploded gross requirements to give the total gross 
requirements that are used in the logic of MRP. Normal netting, exception check- 
ing, and order planning take place. 

The same functions for analyzing abnormal demands and handling past due 
forecasts in the master scheduling system should be available for independent 
demands entered directly into MRP. 
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Distribution Resource Planning 



Distribution Resource Planning is MRP II in a distribution environment. A distri- 
bution network needs the same kinds of scheduling information that is needed in 
scheduling a factory. Knowing what is needed and when is just as important in a 
distribution network as it is in a factory. This same kind of information is also 
needed for a multiplant operation; each of the plants need to know what is needed 
and when. Consequently, this explanation of Distribution Resource Planning cov- 
ers both MRP II in a distribution environment and MRP II in a multiplant opera- 
tion. 

Distribution Resource Planning allows visibility into the entire distribution net- 
work. It allows the central facility to see the actual demands for products that will 
be needed at the distribution centers. The picture of demand at the central facility 
is like that of any other dependent demand item. The demand is lumpy. In some 
weeks the requirements far exceed the average, and in others there are few or 
even no requirements at all. The demands from the distribution centers on the 
central facility are visible as far into the future as the planning horizon extends. 

Distribution Resource Planning also provides an accurate picture of the trans- 
portation loading and scheduling needed to support the distribution schedule. Us- 
ing the projection of transportation requirements by volume, weight, and number 
of pallets, and the tools of MRP, a transportation planner can do a more effective 
job of truck and freight car loading. 

The same type of advantages exist in a multiplant operation. The supplying 
plants are able to truly see into the receiving plants. The requirements for material 
and transportation are clear, and the interplant communication allows planners 
and master scheduler at the supplying plant to see the requirements as far into the 
future as the planning horizon extends. 



»H1» TRANSACTIONS 

_ 1 he basis for Distribution Resource Planning is a material requirements plan- 
ning calculation done for each item at each distribution center or receiving plant. 
J'or each stock keeping unit (SKU) at a distribution center, MRP is run using the 
ccast and any customer orders that are promised for future delivery as gross 
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requirements. For the receiving plants, the master production schedule would be 
the source of requirements for component items. 

In any case, the normal MRP logic nets these requirements against the on-hand 
balance, safety stock, and any scheduled receipts (in-transit orders on the way to 
this branch warehouse or receiving plant) for the stock keeping unit. Planned 
orders are created to cover the remaining gross requirements using the lot sizing 
rule for the SKU. These planned orders will be supplied by the central facility, 
and so they are offset by the lead time for the SKU, exploded, and appear in the 
master schedule report for the central facility or supplying plant as a type of 
demand. 

There are several different ways to translate the planned orders at the distribu- 
tion centers and receiving plants into demands on the master production schedule 
for the supplying facility. They are: 

1 . Using a single data base and bills of material to represent the distribution net- 
work. Each stock keeping unit at each logication has a separate item number, 
typically the product item number and a location identifier. 

2. Using a single data base and a source code on each item/location to identify 
the manufacturing source for that stock keeping unit. A computer program 
translates planned orders for one location into demands on the master schedule 
at the source location. 

3. Using separate data bases and a computer program or programs to translate 
planned orders at the DCs to demand on the master production schedule. 

The bill of material method requires that each stock keeping unit in each ware- 
house has a unique item number. This unique item number is typically the item 
number at the supplying facility plus the warehouse or receiving plant number. 
Then a bill of material is created showing the item number at the receiving loca- 
tion being made from the item number at the central supply location. By including 
a bill of material, the planned orders at the receiving locations will be exploded 
and gross requirements will be posted to the master schedule at the supply loca- 
tion. 

The second method is similar. Each stock keeping unit has a unique item num- 
ber, typically the item number from the supplying facility and a location identi- 
fier. In addition, a code is stored for each SKU to identify the source location. 
The MRP logic is run for each SKU at a location. Then each planned order is 
sent to the supplying location as gross requirements. When this method is used, 
additional explosion logic must be added to the system to properly handle the 
transfer of the gross requirements. 

Another way to show the branch warehouse and multiplant demands is to have 
separate data bases for the different warehouses or receiving plants and the central 
supply facility. MRP is run for each of the warehouses or receiving plants. The 
planned orders are then sent as gross requirements from the branch warehouse or 
receiving plant MRP systems to the master production schedule at the supplying 
location. These gross requirements are treated as demands in the master schedul- 
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ing system for the central facility. When this method is used, logic is included in 
the system to handle the transfer of the gross requirements. 

IN-TRANSIT INFORMATION 

In a distribution or multiplant environment it is also necessary to show the 
material that is in transit to the MRP system. This material is a scheduled receipt 
for the receiving location. The system that maintains these scheduled receipts 
functions like the system that maintains manufacturing scheduled receipts. When 
a movement is created to ship material from the central facility to a distribution 
center or receiving plant, the items in the central facility are allocated to the 
shipment and a scheduled receipt is created at the receiving location. When the 
items are shipped from the central facility, the on-hand balance and the allocation 
are reduced. When the items are received at the branch warehouse or receiving 
plant, the scheduled receipt is reduced and the on-hand balance is increased. This 
same process can also be used when items are shipped from one warehouse to 
another. 

While the system for items that are in transit is similar to the manufacturing 
scheduled receipts system, there are also some differences. Items that are in transit 
require that shipment information be stored for the movement. In addition to the 
movement number, item number, quantity, and date, this information includes 
things like the shipper, means of shipment, freight cost, value of the shipment, 
insurance, and an indication of what is in transit and what has not been shipped. 
For this reason, many times a separate system is used to maintain the information 
on items that are in transit. Other times, the scheduled receipts system for manu- 
facturing items is modified to allow this type of information to be stored. 



TRANSPORTATION PLANNING 

Transportation planning is an integral part of DRP. Accurate transportation 
scheduling and loading, such as accurate capacity requirements planning in a 
manufacturing environment, is a necessity if a distribution network is to be man- 
aged effectively. 

Transportation planning is a way to plan the weight, volume, and number of 
pallets to be shipped based on the distribution resource plan. Transportation plan- 
ning simulates these transportation requirements for the purpose of taking advan- 
tage of freight rates. By simulating the transportation requirements, a company 
can see which periods have less than full truckloads or railcars. By adjusting the 
shipping schedule to ship full truckloads or railcars, at the greatest possible weight, 
a transportation planner can take advantage of the best rates, and, as a result 
minimize freight costs. A real benefit is that the products that must be shipped 
early (in order to have full truckloads) can be determined well in advance, rather 
than left to chance or to what's available at the time the trucks are being loaded. 

The logic of transportation planning is similar to that Capacity Requirements 
Manning. In Capacity Requirements Planning, the planned order quantities are 
extracted from MRP and extended by the standard hours for each operation in the 



172 / MRP II Standard System 



routing. The capacity requirements are then summarized and displayed for each 
work center and time period. 

In transportation planning, the unshipped distribution orders and firm planned 
and planned orders for the distribution centers or receiving plants are extracted 
from DRP and extended by the product weight (for example, pounds) and pack- 
age volume (cubic feet), and divided by the quantity of the product that will lit 
on a pallet or container. These transportation requirements are scheduled for the 
start date of each planned order. After the transportation requirements have been 
generated, they are summarized and displayed by time period. 

A transportation planning report displays the weight, volume, and number ol 
pallets required to ship to each distribution center in each week. Using this report, 
a distribution planner can see into the DRP system, anticipate problems in freight 
car loading, and solve them while there is still time enough to ship the rig hi 
products . 

A transportation planning system must include a transportation planning sum- 
mary report and a report showing the details of the transportation requirements. 
A transportation planning summary report or display shows the totals of the trans 
portation requirements by destination and shipping method, including: 

1. Destination and shipping method descriptive information. 

2. Transportation planning periods (days, weeks, etc.). 

3. Required weight, volume, and number of pallets. 

4. Available transportation capacity in weight, volume, and number of pallets. 

5. Amount over/under available capacity. 

A display of the transportation requirements details is needed to solve trans- 
portation planning problems. This display shows the individual shipments that 
make up the total transportation requirements. 

Many companies plan transportation requirements in weekly time periods, al- 
though in some cases it may be essential to plan daily transportation requirements. 
An example of needing to plan daily transportation requirements is a high volume 
manufacturer of cigarettes or soft drinks. No finished goods storage space exists, 
and product must be shipped daily or more frequently to the distribution sites. In 
this case, planning daily transportation requirements is essential. 

One helpful feature in a transportation planning system is a way to vary the 
transportation capacity in each period. For example, in week twenty a company 
may be adding an additional truck to its company-owned fleet. In this situation, 
a transportation planner will want to increase the capacity available in week twenty 
and each subsequent period. 

FIXED SHIPPING SCHEDULES 

Many distribution companies work to fixed shipping schedules. A fixC( J. sl ^ 
ping schedule establishes the specific days and weeks on which maicnal is ilu Pj*r 
to each distribution center. For example, one shipping schedule nuglH he to s 
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to the Seattle distribution center every third Thursday, to the Boston distribution 
center every other Tuesday, and to the Houston distribution center every Wednes- 
day. 

Working to a fixed shipping schedule solves several problems in distribution. 
For example, a fixed shipping schedule is one way to handle limitations in ship- 
ping doors and docks and in manpower and equipment at either the sending or 
receiving facility. A fixed shipping schedule is a simple way of leveling transpor- 
tation load. 

In a company with a fixed shipping schedule, the Distribution Resource Plan- 
ning system must include a way to define a fixed shipping schedule and logic to 
adjust the planned shipments to the distribution centers to agree with the fixed 
shipping schedule. DRP may plan an order to be shipped to the Seattle distribu- 
tion center on Wednesday of week four. If the shipping schedule for Seattle is 
Thursday of weeks two, five, and eight, DRP will not be a true simulation of 
what will actually happen. 

In this situation, the planned order should be adjusted to ship on Thursday of 
week two and an action message indicating that the order is scheduled for ship- 
ment earlier than needed should be produced for the planner. This way, DRP will 
be an accurate simulation for the resupply, and the master scheduler will be able 
to see that the material is really needed in week two. The action message provides 
a way for the planner to see into the system and to verify that what the system 
has done makes sense. 

There are two methods for adjusting the planned order dates to the shipping 
schedule. One method is to calculate the planned orders based on the date the 
items are needed in the distribution centers. An additional calculation in the order 
planning logic would then adjust the dates to the shipping schedule. The planned 
orders would be moved to the next earlier shipping date. 

The other method would be to use a separate program that adjusts the planned 
orders after DRP has created and stored them. This computer program would read 
the planned orders, adjust them to the next earlier shipping date, and, if neces- 
sary, update the distribution demands on the master production schedule. This 
method of having a separate program is often used when it is difficult, or imprac- 
tical, to modify the logic of MRP in a software package. 



